Apparatus and method for aggregating web services

ABSTRACT

An apparatus and method for aggregating web services in generating a user interface for a computing device. Web service descriptions are received that define a web service interface to each of a plurality of web services. The web service descriptions are processed to identify inputs to first web services obtainable by invoking one or more second web services. A user interface is generated for the computing device that aggregates these first and second web services. By identifying instances in which the input to one web service may be obtained by invoking another web service, a user interface which aggregates these web services may be automatically generated.

CROSS REFERENCE TO RELATED APPLICATION

This application is a continuation of prior U.S. patent application Ser.No. 10/786,018, filed on Feb. 26, 2004, the entirety of which is herebyincorporated by reference.

FIELD OF THE INVENTION

Embodiments of the invention relate generally to web services, and moreparticularly to a method of aggregating web services in the generationof user interfaces for computing devices.

BACKGROUND OF THE INVENTION

A web service can be generally defined as one or more applicationfunctions that can be invoked over the Internet using a protocol. Oneexample of a protocol that may be used in this context is the SimpleObject Access Protocol (SOAP), which may be used by Internet-basedapplication servers, also known as web servers, to provide web services.SOAP is a protocol that is often used in the exchange of information indecentralized, distributed network environments.

One goal of web services is to use the infrastructure of the web toprovide information that is machine-readable. Unlike traditionalclient/server models such as a web server/web page system, web servicesdo not typically provide the user with a graphical user interface (GUI),but instead share business logic, data, and processes through aprogrammatic interface across a network. As applications are capable ofinterfacing with web services, developers may add web services to a GUI(e.g. a web page or executable program) to offer specific functionalityto users.

Furthermore, different applications from different sources cancommunicate with each other without extensive custom coding, and webservices are not associated with any one operating system or programminglanguage. This flexibility allows more sophisticatedbusiness-to-business applications as well as more sophisticated browsingmodels (with more client-side processing of data) to be developed.

For simple applications, it may be sufficient to have a one-to-onerelationship between a user action, a page displayed to a user through auser interface on a computing device, and a web service. However, thislimitation would typically be overly restrictive for more complexapplications. In many applications, a single page displayed to the userrepresents an aggregation of multiple types of data. Similarly, a singleuser action may result in several types of data being examined andmodified. Many web services are designed to perform small tasks or unitsof work; this modularity permits aggregation with other web services inthe development of applications.

One known solution for aggregating web services is for a programmer towrite customized code for a client application that provides thisaggregation. Typically, the client application provides the aggregationof web services to provide a meaningful end user experience. However,writing customized client applications requires time and skill. Theseclient applications must usually be distributed to each endpoint (e.g.client computing device) before they can be used. Furthermore, clientapplications must also be rewritten and specifically customized for eachtarget platform.

SUMMARY OF THE INVENTION

Embodiments of the invention relate generally to web services, and morespecifically to methods that facilitate the aggregation of web services,which do not require programmers to write customized code.

In a broad aspect of the invention, there is provided a method ofaggregating web services in generating a user interface for a computingdevice, the method comprising the steps of: receiving at least one webservice description, wherein the at least one web service descriptioncomprises a plurality of web service description elements that define aweb service interface to each of a plurality of web services; processingthe at least one web service description to identify a first web servicerequiring one or more inputs, wherein each input to the first webservice is obtainable by invoking a second web service of the pluralityof web services; and generating a user interface for the computingdevice adapted invoke one or more second web services to obtain outputdata from the one or more second web services; and invoking the firstweb service, using output data from the second web services as inputdata to the first web service, to obtain output data from the first webservice.

By identifying instances in which the input to one web service may beobtained by invoking another web service, a client application thatprovides a user interface which aggregates these web services may beautomatically generated.

In one embodiment of the invention, various web service descriptionelements contained in one or more web service descriptions contain namesof web services and inputs to web services that adhere to apredetermined naming convention. This facilitates a determination ofwhether an input to one web service may be obtained by invoking anotherweb service.

In another embodiment of the invention, input data is received as inputby users to invoke web services, and output data output by invoked webservices is displayed to users, through one or more user interfaces. Byidentifying patterns in the input data input by users and output datadisplayed to users that suggest that an input to one web service may beobtained by invoking another web service, a new user interface whichaggregates these web services can be generated.

In another embodiment of the invention in which input data is receivedas input by users to invoke web services, and output data output byinvoked web services is displayed to user, through one or more userinterfaces, specific user interactions (e.g. a copying of output data toan input field) are detected and used to determine whether an input toone web service may be obtained by invoking another web service.

In another embodiment of the invention, a user interface is providedthat permits users to explicitly associate web services by identifyingwhich inputs of a specific web service may be obtained by invokinganother web service. This information can then be used to generate a newuser interface which aggregates these web services.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other features of embodiments of the invention will be madeapparent from the following description, with reference to theaccompanying drawings, in which:

FIG. 1 is a block diagram which illustrates components of a mobiledevice which communicates within a wireless communication network;

FIG. 2 is a schematic diagram illustrating components of the mobiledevice of FIG. 1;

FIG. 3 is an example structure of a system for communication with themobile device;

FIG. 4 is a schematic diagram that illustrates a mobile device connectedto a web server over a connection in a wireless communication network;

FIG. 5 is a flowchart illustrating a method of aggregating web servicesin generating a user interface in accordance with an embodiment of theinvention;

FIG. 6 is a flowchart illustrating a method of aggregating web servicesin generating a user interface in accordance with another embodiment ofthe invention; and

FIG. 7 is a schematic diagram depicting a series of example screensdisplayed to a user in an example implementation of an embodiment of theinvention.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

FIG. 1 is a block diagram of a communication system 100, which includesa mobile device 102 that communicates through a wireless communicationnetwork 104. Mobile device 102 preferably includes a visual display 112,a keyboard 114, and perhaps one or more auxiliary user interfaces (UI)116, each of which is coupled to a controller 106. Controller 106 isalso coupled to radio frequency (RF) transceiver circuitry 108 and anantenna 110.

Typically, controller 106 is embodied as a central processing unit(CPU), which runs operating system software in a memory component (notshown). Controller 106 will normally control overall operation of mobiledevice 102, whereas signal processing operations associated withcommunication functions are typically performed in RF transceivercircuitry 108. Controller 106 interfaces with device display 112 todisplay received information, stored information, user inputs, and thelike. Keyboard 114, which may be a telephone type keypad or fullalphanumeric keyboard, is normally provided for entering data forstorage in mobile device 102, information for transmission to network104, a telephone number to place a telephone call, commands to beexecuted on mobile device 102, and possibly other or different userinputs.

Mobile device 102 sends communication signals to and receivescommunication signals from network 104 over a wireless link via antenna110. RF transceiver circuitry 108 performs functions such asmodulation/demodulation and possibly encoding/decoding andencryption/decryption. It will be apparent to those skilled in art thatRF transceiver circuitry 108 will be adapted to particular wirelessnetwork or networks in which mobile device 102 is intended to operate.

Mobile device 102 includes a battery interface 134 for receiving one ormore rechargeable batteries 132. Battery 132 provides electrical powerto electrical circuitry in mobile device 102, and battery interface 132provides for a mechanical and electrical connection for battery 132.Battery interface 132 is coupled to a regulator 136, which regulatespower to the device. When mobile device 102 is fully operational, an RFtransmitter of RF transceiver circuitry 108 is typically keyed or turnedon only when it is sending to a network, and is otherwise turned off toconserve resources. Similarly, an RF receiver of RF transceivercircuitry 108 is typically periodically turned off to conserve poweruntil it is needed to receive signals or information (if at all) duringdesignated time periods.

Mobile device 102 operates using a Subscriber Identity Module (SIM) 140which is connected to or inserted in mobile device 102 at a SIMinterface 142. SIM 140 is one type of a conventional “smart card” usedto identify an end user (or subscriber) of mobile device 102 and topersonalize the device, among other things. Without SIM 140, the mobiledevice terminal is not fully operational for communication throughwireless network 104. By inserting SIM 140 into mobile device 102, anend user can have access to any and all of his/her subscribed services.SIM 140 generally includes a processor and memory for storinginformation. Since SIM 140 is coupled to SIM interface 142, it iscoupled to controller 106 through communication lines 144. In order toidentify the subscriber, SIM 140 contains some user parameters such asan International Mobile Subscriber Identity (IMSI). An advantage ofusing SIM 140 is that end users are not necessarily bound by any singlephysical mobile device. SIM 140 may store additional user informationfor the mobile device as well, including datebook (or calendar)information and recent call information.

Mobile device 102 may consist of a single unit, such as a datacommunication device, a cellular telephone, a multiple-functioncommunication device with data and voice communication capabilities, apersonal digital assistant (PDA) enabled for wireless communication, ora computer incorporating an internal modem. Alternatively, mobile device102 may be a multiple-module unit comprising a plurality of separatecomponents, including but in no way limited to a computer or otherdevice connected to a wireless modem. In particular, for example, in themobile device block diagram of FIG. 1, RF transceiver circuitry 108 andantenna 110 may be implemented as a radio modem unit that may beinserted into a port on a laptop computer. In this case, the laptopcomputer would include display 112, keyboard 114, one or more auxiliaryUIs 116, and controller 106 embodied as the computer's CPU. It is alsocontemplated that a computer or other equipment not normally capable ofwireless communication may be adapted to connect to and effectivelyassume control of RF transceiver circuitry 108 and antenna 110 of asingle-unit device such as one of those described above. Such a mobiledevice 102 may have a more particular implementation as described laterin relation to mobile device 202 of FIG. 2.

Mobile device 102 communicates in and through wireless communicationnetwork 104. In the embodiment of FIG. 1, wireless network 104 isconfigured in accordance with General Packet Radio Service (GPRS) and aGlobal Systems for Mobile (GSM) technologies. Wireless network 104includes a base station controller (BSC) 120 with an associated towerstation 118, a Mobile Switching Center (MSC) 122, a Home LocationRegister (HLR) 132, a Serving General Packet Radio Service (GPRS)Support Node (SGSN) 126, and a Gateway GPRS Support Node (GGSN) 128. MSC122 is coupled to BSC 120 and to a landline network, such as a PublicSwitched Telephone Network (PSTN) 124. SGSN 126 is coupled to BSC 120and to GGSN 128, which is in turn coupled to a public or private datanetwork 130 (such as the Internet). HLR 132 is coupled to MSC 122, SGSN126, and GGSN 128.

Station 118 is a fixed transceiver station, and station 118 and BSC 120are together referred to herein as the fixed transceiver equipment. Thefixed transceiver equipment provides wireless network coverage for aparticular coverage area commonly referred to as a “cell”. The fixedtransceiver equipment transmits communication signals to and receivescommunication signals from mobile devices within its cell via station118. The fixed transceiver equipment normally performs such functions asmodulation and possibly encoding and/or encryption of signals to betransmitted to the mobile device in accordance with particular, usuallypredetermined, communication protocols and parameters, under control ofits controller. The fixed transceiver equipment similarly demodulatesand possibly decodes and decrypts, if necessary, any communicationsignals received from mobile device 102 within its cell. Communicationprotocols and parameters may vary between different networks. Forexample, one network may employ a different modulation scheme andoperate at different frequencies than other networks.

The wireless link 150 of FIG. 1 represents one or more differentchannels, typically different radio frequency (RF) channels, andassociated protocols used between wireless network 104 and mobile device102. An RF channel is a limited resource that must be conserved,typically due to limits in overall bandwidth and a limited battery powerof mobile device 102. Those skilled in art will appreciate that awireless network in actual practice may include hundreds of cells, eachserved by a station 118 (or station sector), depending upon desiredoverall expanse of network coverage. All pertinent components may beconnected by multiple switches and routers (not shown), controlled bymultiple network controllers.

For all mobile devices 102 registered with a network operator, permanentdata (such as mobile device 102 user's profile) as well as temporarydata (such as mobile device's 102 current location) are stored in HLR132. In case of a voice call to mobile device 102, HLR 132 is queried todetermine the current location of mobile device 102. A Visitor LocationRegister (VLR) of MSC 122 is responsible for a group of location areasand stores the data of those mobile devices that are currently in itsarea of responsibility. This includes parts of the permanent mobiledevice data that have been transmitted from HLR 132 to the VLR forfaster access. However, the VLR of MSC 122 may also assign and storelocal data, such as temporary identifications. Optionally, the VLR ofMSC 122 can be enhanced for more efficient co-ordination of GPRS andnon-GPRS services and functionality (e.g. paging for circuit-switchedcalls which can be performed more efficiently via SGSN 126, and combinedGPRS and non-GPRS location updates).

Serving GPRS Support Node (SGSN) 126 is at the same hierarchical levelas MSC 122 and keeps track of the individual locations of mobiledevices. SGSN 126 also performs security functions and access control.Gateway GPRS Support Node (GGSN) 128 provides interworking with externalpacket-switched networks and is connected with SGSNs (such as SGSN 126)via an IP-based GPRS backbone network. SGSN 126 performs authenticationand cipher setting procedures based on the same algorithms, keys, andcriteria as in existing GSM. In conventional operation, cell selectionmay be performed autonomously by mobile device 102 or by the fixedtransceiver equipment instructing mobile device 102 to select aparticular cell. Mobile device 102 informs wireless network 104 when itreselects another cell or group of cells, known as a routing area.

In order to access GPRS services, mobile device 102 first makes itspresence known to wireless network 104 by performing what is known as aGPRS “attach”. This operation establishes a logical link between mobiledevice 102 and SGSN 126 and makes mobile device 102 available toreceive, for example, pages via SGSN, notifications of incoming GPRSdata, or SMS messages over GPRS. In order to send and receive GPRS data,mobile device 102 assists in activating the packet data address that itwants to use. This operation makes mobile device 102 known to GGSN 128;interworking with external data networks can thereafter commence. Userdata may be transferred transparently between mobile device 102 and theexternal data networks using, for example, encapsulation and tunneling.Data packets are equipped with GPRS-specific protocol information andtransferred between mobile device 102 and GGSN 128.

Those skilled in art will appreciate that a wireless network may beconnected to other systems, possibly including other networks, notexplicitly shown in FIG. 1. A network will normally be transmitting atvery least some sort of paging and system information on an ongoingbasis, even if there is no actual packet data exchanged. Although thenetwork consists of many parts, these parts all work together to resultin certain behaviours at the wireless link.

FIG. 2 is a detailed block diagram of a mobile device 202 (e.g. mobiledevice 102 of FIG. 1). Mobile device 202 is preferably a two-waycommunication device having at least voice and advanced datacommunication capabilities, including the capability to communicate withother computer systems. Depending on the functionality provided bymobile device 202, it may be referred to as a data messaging device, atwo-way pager, a cellular telephone with data messaging capabilities, awireless Internet appliance, or a data communication device (with orwithout telephony capabilities). Mobile device 202 may communicate withany one of a plurality of fixed transceiver stations 200 within itsgeographic coverage area.

Mobile device 202 will normally incorporate a communication subsystem211, which includes a receiver 212, a transmitter 214, and associatedcomponents, such as one or more (preferably embedded or internal)antenna elements 216 and 218, local oscillators (LOs) 213, and aprocessing module such as a digital signal processor (DSP) 220.Communication subsystem 211 is analogous to RF transceiver circuitry 108and antenna 110 shown in FIG. 1. As will be apparent to those skilled infield of communications, particular design of communication subsystem211 depends on the communication network in which mobile device 202 isintended to operate.

Mobile device 202 may send and receive communication signals over thenetwork after required network registration or activation procedureshave been completed. Signals received by antenna 216 through the networkare input to receiver 212, which may perform such common receiverfunctions as signal amplification, frequency down conversion, filtering,channel selection, and like, and in example shown in FIG. 2,analog-to-digital (A/D) conversion. A/D conversion of a received signalallows more complex communication functions such as demodulation anddecoding to be performed in DSP 220. In a similar manner, signals to betransmitted are processed, including modulation and encoding, forexample, by DSP 220. These DSP-processed signals are input totransmitter 214 for digital-to-analog (D/A) conversion, frequency upconversion, filtering, amplification and transmission over communicationnetwork via antenna 218. DSP 220 not only processes communicationsignals, but also provides for receiver and transmitter control. Forexample, the gains applied to communication signals in receiver 212 andtransmitter 214 may be adaptively controlled through automatic gaincontrol algorithms implemented in DSP 220.

Network access is associated with a subscriber or user of mobile device202, and therefore mobile device 202 requires a Subscriber IdentityModule or “SIM” card 262 to be inserted in a SIM interface 264 in orderto operate in the network. SIM 262 includes those features described inrelation to FIG. 1. Mobile device 202 is a battery-powered device so italso includes a battery interface 254 for receiving one or morerechargeable batteries 256. Such a battery 256 provides electrical powerto most, if not all electrical circuitry in mobile device 202, andbattery interface 254 provides for a mechanical and electricalconnection for it. The battery interface 254 is coupled to a regulator(not shown), which provides power V+ to all of the circuitry.

Mobile device 202 includes a microprocessor 238 (which is oneimplementation of controller 106 of FIG. 1), which controls overalloperation of mobile device 202. Communication functions, including atleast data and voice communications, are performed through communicationsubsystem 211. Microprocessor 238 also interacts with additional devicesubsystems such as a display 222, a flash memory 224, a random accessmemory (RAM) 226, auxiliary input/output (I/O) subsystems 228, a serialport 230, a keyboard 232, a speaker 234, a microphone 236, a short-rangecommunications subsystem 240, and any other device subsystems generallydesignated at 242. Some of the subsystems shown in FIG. 2 performcommunication-related functions, whereas other subsystems may provide“resident” or on-device functions. Notably, some subsystems, such askeyboard 232 and display 222, for example, may be used for bothcommunication-related functions, such as entering a text message fortransmission over a communication network, and device-resident functionssuch as a calculator or task list. Operating system software used bymicroprocessor 238 is preferably stored in a persistent store such asflash memory 224, which may alternatively be a read-only memory (ROM) orsimilar storage element (not shown). Those skilled in the art willappreciate that the operating system, specific device applications, orparts thereof, may be temporarily loaded into a volatile store such asRAM 226.

Microprocessor 238, in addition to its operating system functions,preferably enables execution of software applications on mobile device202. A predetermined set of applications which control basic deviceoperations, including at least data and voice communication applications(such as a network reestablishment scheme), will normally be installedon mobile device 202 during its manufacture. A preferred applicationthat may be loaded onto mobile device 202 may be a personal informationmanager (PIM) application having the ability to organize and manage dataitems relating to user such as, but not limited to, e-mail, calendarevents, voice mails, appointments, and task items. Naturally, one ormore memory stores are available on mobile device 202 and SIM 256 tofacilitate storage of PIM data items and other information.

The PIM application preferably has the ability to send and receive dataitems via the wireless network. In a preferred embodiment, PIM dataitems are seamlessly integrated, synchronized, and updated via thewireless network, with the mobile device user's corresponding data itemsstored and/or associated with a host computer system thereby creating amirrored host computer on mobile device 202 with respect to such items.This is especially advantageous where the host computer system is themobile device user's office computer system. Additional applications mayalso be loaded onto mobile device 202 through the communicationsnetwork, an auxiliary I/O subsystem 228, serial port 230, short-rangecommunications subsystem 240, or any other suitable subsystem 242, andinstalled by a user in RAM 226 or preferably a non-volatile store (notshown) for execution by microprocessor 238. Such flexibility inapplication installation increases the functionality of mobile device202 and may provide enhanced on-device functions, communication-relatedfunctions, or both. For example, secure communication applications mayenable electronic commerce functions and other such financialtransactions to be performed using mobile device 202.

In a data communication mode, a received signal such as a text message,an e-mail message, or web page download will be processed bycommunication subsystem 211 and input to microprocessor 238.Microprocessor 238 will preferably further process the signal for outputto display 222 or alternatively to auxiliary I/O device 228. A user ofmobile device 202 may also compose data items, such as e-mail messages,for example, using keyboard 232 in conjunction with display 222 andpossibly auxiliary I/O device 228. Keyboard 232 is preferably a completealphanumeric keyboard and/or telephone-type keypad. These composed itemsmay be transmitted over a communication network through communicationsubsystem 211.

For voice communications, the overall operation of mobile device 202 issubstantially similar, except that the received signals would be outputto speaker 234 and signals for transmission would be generated bymicrophone 236. Alternative voice or audio I/O subsystems, such as avoice message recording subsystem, may also be implemented on mobiledevice 202. Although voice or audio signal output is preferablyaccomplished primarily through speaker 234, display 222 may also be usedto provide an indication of the identity of a calling party, duration ofa voice call, or other voice call related information, as some examples.

Serial port 230 in FIG. 2 is normally implemented in a personal digitalassistant (PDA)-type communication device for which synchronization witha user's desktop computer is a desirable, albeit optional, component.Serial port 230 enables a user to set preferences through an externaldevice or software application and extends the capabilities of mobiledevice 202 by providing for information or software downloads to mobiledevice 202 other than through a wireless communication network. Thealternate download path may, for example, be used to load an encryptionkey onto mobile device 202 through a direct and thus reliable andtrusted connection to thereby provide secure device communication.

Short-range communications subsystem 240 of FIG. 2 is an additionaloptional component which provides for communication between mobiledevice 202 and different systems or devices, which need not necessarilybe similar devices. For example, subsystem 240 may include an infrareddevice and associated circuits and components, or a Bluetooth™communication module to provide for communication with similarly-enabledsystems and devices. Bluetooth™ is a registered trademark of BluetoothSIG, Inc.

FIG. 3 shows an example system structure for communicating with a mobiledevice. In particular, FIG. 3 shows basic components of one example ofan IP-based wireless data network which may be utilized. Mobile device302 (e.g. mobile device 102 and 202 of FIG. 1 and FIG. 2 respectively)communicates with a wireless packet data network 305, and may also becapable of communicating with a wireless voice network (not shown). Asshown in FIG. 3, a gateway 310 may be coupled to an internal or externaladdress resolution component 315 and one or more network entry points320. Data packets are transmitted from gateway 310, which is a source ofinformation to be transmitted to mobile device 302, through network 305by setting up a wireless network tunnel 325 from gateway 310 to mobiledevice 302. In order to create this wireless tunnel 325, a uniquenetwork address is associated with mobile device 302. In an IP-basedwireless network, however, network addresses are typically notpermanently assigned to a particular mobile device 302 but instead aredynamically allocated on an as-needed basis. It is thus preferable formobile device 302 to acquire a network address and for gateway 310 todetermine this address so as to establish wireless tunnel 325.

Network entry point 320 is generally used to multiplex and demultiplexamongst many gateways, corporate servers, and bulk connections such asthe Internet, for example. There are normally very few of these networkentry points 320, since they are also intended to centralize externallyavailable wireless network services. Network entry points 320 often usesome form of an address resolution component 315 that assists in addressassignment and lookup between gateways and mobile devices. In thisexample, address resolution component 315 is shown as a dynamic hostconfiguration protocol (DHCP) as one method for providing an addressresolution mechanism.

A central internal component of wireless data network 305 is a networkrouter 330. Normally, network routers 330 are proprietary to theparticular network, but they could alternatively be constructed fromstandard commercially available hardware. The purpose of network routers330 is to centralize thousands of fixed transceiver stations 335normally implemented in a relatively large network into a centrallocation for a long-haul connection back to network entry point 320. Insome networks there may be multiple tiers of network routers 330 andcases where there are master and slave network routers 330, but in allsuch cases the functions are similar. Often a network router 330 willaccess a name server 340, in this case shown as a dynamic name server(DNS) 340 as used in the Internet, to look up destinations for routingdata messages. Fixed transceiver stations 335, as described above,provide wireless links to mobile devices such as mobile device 302.

Wireless network tunnels such as a wireless tunnel 325 are opened acrosswireless network 305 in order to allocate necessary memory, routing, andaddress resources to deliver IP packets. Such tunnels 325 areestablished as part of what are referred to as Packet Data Protocol or“PDP contexts” (i.e. data sessions). To open wireless tunnel 325, mobiledevice 302 must use a specific technique associated with wirelessnetwork 305. The step of opening such a wireless tunnel 325 may requiremobile device 302 to indicate the domain, or network entry point 320with which it wishes to open wireless tunnel 325. In this example, thetunnel first reaches network router 330 which uses name server 340 todetermine which network entry point 320 matches the domain provided.Multiple wireless tunnels can be opened from one mobile device 302 forredundancy, or to access different gateways and services on the network.Once the domain name is found, the tunnel is then extended to networkentry point 320 and necessary resources are allocated at each of thenodes along the way. Network entry point 320 then uses the addressresolution component 315 to allocate an IP address for mobile device302. When an IP address has been allocated to mobile device 302 andcommunicated to gateway 310, information can then be forwarded fromgateway 310 to mobile device 302.

Wireless tunnel 325 typically has a limited life, depending on mobiledevice's 302 coverage profile and activity. Wireless network 305 willtear down wireless tunnel 325 after a certain period of inactivity orout-of-coverage period, in order to recapture resources held by thiswireless tunnel 325 for other users. The main reason for this is toreclaim the IP address temporarily reserved for mobile device 302 whenwireless tunnel 325 was first opened. Once the IP address is lost andwireless tunnel 325 is torn down, gateway 310 loses all ability toinitiate IP data packets to mobile device 302, whether over TransmissionControl Protocol (TCP) or over User Datagram Protocol (UDP).

Referring to FIG. 4, there is shown a schematic diagram that illustratesa mobile device 202 connected to a web server 405 over a connection 410in a wireless data network (e.g. wireless network 305 of FIG. 3). Webserver 405 is a provider of web services. Generally, web services areself-contained, self-describing modular applications that can bedeployed (i.e. published), located, and invoked across the World WideWeb (the “Web”). Other applications, including other web services, candiscover deployed web services and invoke them.

A basic web service platform is based on the Extensible Markup Language(XML) and the Hyper Text Transfer Protocol (HTTP). XML provides ametalanguage in which specialized languages may be written to expresscomplex interactions between clients and services, or between componentsof a composite service. Web server 405 will typically convert XMLmessages into a middleware request, and convert results back into XML.

This basic platform is augmented with several other platform services toconstitute a more functional platform. A fully-functional web servicesplatform further consists of three additional elements: the SimpleObject Access Protocol (SOAP), the Universal Description, Discovery andIntegration Service (UDDI) [not shown], and the Web Services DescriptionLanguage (WSDL).

SOAP is a protocol specification that defines a uniform way of passingdata as an XML message. SOAP can be synchronous (e.g. a remote procedurecall) or asynchronous (e.g. a message). In particular, SOAP is oneexample of a protocol that may be used to encode the information in webservice requests and response messages before they are sent over anetwork.

UDDI is used for listing what web services are available, and provides amechanism for clients to dynamically find specific web services. It is aWeb-based distributed directory that enables web service publishers (whohave information or services to share) to register themselves, and forclients or web service consumers (who want information or services) tosearch these registries. When an appropriate web service has been found,a description of this service may be retrieved.

WSDL is a way to describe a web service. More specifically, WSDLprovides a way for web service providers to describe the basic format ofweb service requests over different protocols or encodings. WSDL is anXML description of a web service, which describes what the web servicecan do, where it resides, and how to invoke it.

In one embodiment of the invention, a web service description isembodied in a WSDL file. WSDL files include all the information neededto use a web service including the format of the message web server 405is expecting, and the location of web server 405 on a network.Furthermore, WSDL files can be converted into code which will invoke aweb service.

WSDL defines services as collections of network communication endpointsor ports capable of exchanging messages. In WSDL, the abstractdefinition of endpoints and messages is separated from their concretenetwork deployment or data format bindings. This allows the reuse ofabstract definitions of messages, which are abstract descriptions of thedata being exchanged, and port types, which are abstract collections ofoperations. The concrete protocol and data format specifications for aparticular port type constitute a reusable binding. A port is defined byassociating a network address with a reusable binding, and a collectionof ports defines a service. Accordingly, a WSDL document uses thefollowing elements (also referred to herein as web service descriptionelements):

Types:

-   -   a container for data type definitions using some type system        (e.g. XML Schema Definition or XSD);

Message:

-   -   an abstract, typed definition of the data being communicated;

Operation:

-   -   an abstract description of an action supported by the service;

Port Type:

-   -   an abstract set of operations supported by one or more        endpoints;

Binding:

-   -   a concrete protocol and data format specification for a        particular port type;

Port:

-   -   a single endpoint defined as a combination of a binding and a        network address; and

Service:

-   -   a collection of related endpoints.

While SOAP may be used as the invocation protocol for communicationsbetween mobile device 202 and web server 405, other protocols andmessage formats may also be used to communicate with a web service (e.g.HTTP GET/POST, Multipurpose Internet Mail Extensions or MIME).

Embodiments of the invention relate generally to web services, and morespecifically to methods that facilitate the combination or aggregationof web services, but which do not require programmers to writecustomized code. In accordance with one embodiment of the invention, auser interface (UI) is generated automatically from a web servicesdescription. In this embodiment, information in the web servicesdescription is used to combine web services.

Aggregation of web services may also be user-driven. In this case, theaggregation is driven by the consumption of individual web services by auser. In one embodiment of the invention, output data from web servicesbeing displayed to a user through a user interface and input dataentered by a user through the user interface are monitored. In thisembodiment, relationships between web services can be inferred frompatterns in the monitored data. These relationships may suggest whichweb services may be combined. In another embodiment of the invention,relationships between web services may be inferred from the actions of auser manipulating a user interface while consuming a web service.Specific user actions (e.g. when a user copies output data from aninvoked web service, to an input field used to provide input data toanother web service) can be detected in determining which web servicescan be combined.

Aggregation of web services may also be performed by a user, where theuser explicitly specifies how web services should be combined. In oneembodiment of the invention, the user combines web services through amenu-driven interface in which web services available for aggregationare displayed.

In embodiments of the invention described above, the aggregation of webservices is automated, so that the intervention of a human programmer towrite customized client applications is not required to perform theaggregation. Other features of these embodiments of the invention willnow be described in greater detail with reference to FIG. 5 through FIG.7.

Referring to FIG. 5, a flowchart illustrating a method of aggregatingweb services in generating a user interface in accordance with anembodiment of the invention is shown generally as 500.

At step 510, one or more web service descriptions are received by thecomputing device (e.g. mobile device 202 of FIG. 4), as may be requiredto support one or more applications to be executed on the mobile device.For example, a web services description may be in the form of a WSDLfile. Where the computing device is a mobile device, optionally, the webservices description may be optimized by a web services acceleratorbefore it is received by the mobile device, as described in a co-pendingapplication by the same inventors entitled AN APPARATUS AND METHOD FORPROCESSING WEB SERVICE DESCRIPTIONS, the contents of which areincorporated herein by reference. The WSDL file may be obtained from alocation identified on the UDDI registry, for example. Other registrymethods can also be used to locate the appropriate WSDL file, includingvendor specific registry protocols and human readable web based systems,for example.

Web service descriptions received at this step comprise various webservice description elements, and may be processed in accordance withthis embodiment of the invention if the web description elements containnames of web services and inputs to web services that adhere to apredetermined naming convention. The naming convention facilitatesdeterminations of whether an input to one web service may be obtained byinvoking another web service. Put another way, the naming convention maygive hints on how various web services interrelate.

For instance, aggregation may be inferred from the structure of a WSDLfile. WSDL files can describe several logical services and arethemselves a form of aggregation. Information in the WSDL may be used tocombine web services if the author of the WSDL file used some specificnaming convention to provide hints on how individual web services shouldbe combined. The naming convention may be a standardized convention orone that is applied only to a specific set of one or more web services.

Consider the following example. Suppose a WSDL file describes thefollowing three web services:

-   -   (a) getISBN: which takes strings Title and Author as input and        returns an integer;    -   (b) getPrice: which takes an integer ISBN as input and returns a        floating-point number; and    -   (c) order which takes an integer ISBN as input and returns a        string.        In this example, the naming convention used specifies that a web        service having name get<variable> will return a value        <variable>, which can then be used as inputs to other web        services. In this case, getISBN is a web service that returns        data that can be associated with the name ISBN. When ISBN is        used as the name of an input to one or more other web services        (e.g. getPrice and order), an inference can be made that the        output of getISBN may be used as an input to these other web        services.

At step 512, the computing device receiving the web service descriptionsat step 510 may determine if an associated user interface has beenpreviously generated, which already reflects an aggregation ofassociated web services. This step may be performed if re-processing ofthe web service descriptions to aggregate associated web services is notdesired. In variant embodiments of the invention, the determination madeat this step may be performed remotely from the computing device forwhich the user interface will be generated (e.g. by a web servicesaccelerator on a remote server).

At step 514, if an associated user interface has not been previouslygenerated, or where a re-processing of web service descriptions receivedat step 510 is desired, the web service descriptions are processed byparsing the web service descriptions to determine inputs and outputs toassociated web services, and to identify any instances where the inputto a web service might be obtained by invoking another web service (i.e.either by invoking a different web service, or through anotherinvocation of the same web service) as suggested by the names of the webservices and inputs to the web services described in the web servicedescriptions.

At step 516, a user interface is generated from the web servicedescriptions, which may aggregate a number of web services (and/orinstances where a web service is invoked) based on determinations madeduring the processing of the web service descriptions at step 514. Inthis embodiment of the invention, the user interface is generated by thecomputing device, although in variant embodiments of the invention, thisstep may be performed by a device different from the computing device onwhich the user interface will be used (e.g. by a web servicesaccelerator on a remote server).

The user interface may be generated using any of a number of knownmethods. For example, the user interface may be generated by producingcode, which can be executed immediately after it is produced, orconcurrently as it is produced. Alternatively, the code may betemporarily stored in a storage device or memory for subsequentexecution. The code may be produced in the form of an executableapplication, or be in the form of source code to be subsequentlycompiled into an executable format, for example. The code may be in theform of data that can be used by other applications or interfaces (e.g.web browsers) to provide the user interface to users.

The user interface generated at this step aggregates web services, suchthat the outputs of one or more web services when invoked (which may ormay not themselves require input data in order to be invoked) can beused as inputs to one or more different web services or furtherinvocations of the same web service. Accordingly, while a given userinterface may require multiple web services to be invoked, some of theseweb services can be invoked automatically without requiring the user toprovide additional input to each web service or to manually invoke eachweb service.

The user interface is adapted to prompt a user for input data andreceive input data where required to invoke one or more web services. Itwill generally be necessary to obtain input data from the user when thedata required to invoke a web service cannot be obtained by invokingother available web services either directly or indirectly using inputdata already received. The user interface is further adapted to invokeat least one web service to obtain output data (e.g. using inputobtained from the user, using input obtained from previous invocationsof web services, using input taken from the state of the device such asthe available memory, using input taken from the device environment suchas location, using any other parameter available to the device as input,or using no input if it is not required by the web service), and toautomatically invoke another web service using that output data as inputthereto (and possibly other inputs as noted above) if appropriate, asdetermined at step 514. The latter web service need not necessarily be adifferent web service, but may alternatively be a subsequent invocationof the former web service. The user interface may then use the outputdata from the latter web service in a similar manner (e.g. as input datato automatically invoke yet another web service), and/or display theoutput data from the latter web service in a desired output format to auser.

Optionally, at step 518, the user interface generated at step 516 may bestored in a storage device or memory for later retrieval at step 520 inthe event that the generated user interface is to be re-used, as may bedetermined at step 512. Techniques used to track user interfaces thatcan be re-used (e.g. a data table to associate certain sets of one ormore WSDL files with a user interface) as known in the art may beimplemented. The storage device may be locally coupled to the computingdevice, or located remote from the computing device, for example. Userinterfaces that have been generated and stored may themselves offerfunctionality that can be provided as web services.

At step 522, the user interface generated at step 516 is provided to theuser, through a display of the computing device for example. Ifnecessary, the user interface is retrieved from a remote device. Userinteraction through the user interface causes one or more web servicesto be invoked, as may be dictated by the user interface. Due to theaggregation of web services in the user interface, it is not necessaryfor the user to provide input data to invoke each web service that theuser interface might access. The aggregation allows the output of one ormore web services to be automatically used as inputs to other webservices (or other invocations of the same web services).

Referring to FIG. 6, a flowchart illustrating a method of aggregatingweb services in generating a user interface in accordance with anotherembodiment of the invention is shown generally as 600.

At step 610, one or more web service descriptions are received by thecomputing device (e.g. mobile device 202 of FIG. 4), as may be requiredto support one or more applications to be executed on the mobile device.For example, a web services description may be in the form of a WSDLfile. Where the computing device is a mobile device, optionally, the webservices description may be optimized by a web services acceleratorbefore it is received by the mobile device. The WSDL file may beobtained from a location identified on the UDDI registry, for example.Other registry methods can also be used to locate the appropriate WSDLfile, including vendor specific registry protocols and human readableweb based systems, for example.

At step 612, the computing device receiving the web service descriptionsat step 610 may determine if an associated user interface has beenpreviously generated, which already reflects an aggregation ofassociated web services. This step may be performed if re-processing ofthe web service descriptions to aggregate associated web services is notdesired. In variant embodiments of the invention, the determination madeat this step may be performed remotely from the computing device forwhich the user interface will be generated (e.g. by a web servicesaccelerator on a remote server). If a previously generated userinterface is available, the user interface is retrieved at step 614(from a remote device if necessary), and provided to the user at step616, through a display of the computing device for example. Userinteraction through the user interface causes one or more web servicesto be invoked, as may be dictated by the user interface.

At step 618, if an associated user interface has not been previouslygenerated, or where a re-processing of web service descriptions receivedat step 610 is desired, the web service descriptions are processed byparsing the web service descriptions to determine inputs and outputs toassociated web services. In variant embodiments of the invention, thedetermination made at this step may be performed remotely from thecomputing device for which the user interface will be generated (e.g. bya web services accelerator on a remote server).

At step 620, a user interface is generated from the web servicedescriptions, based on determinations made during the processing of theweb service descriptions at step 618. In this embodiment of theinvention, the user interface is generated by the computing device,although in variant embodiments of the invention, this step may beperformed by a device different from the computing device on which theuser interface will be used (e.g. by a web services accelerator on aremote server).

At step 622, the user interface generated at step 620 is provided to theuser, through a display of the computing device for example. Ifnecessary, the user interface is retrieved from a remote device. Userinteraction through the user interface causes one or more web servicesto be invoked, as may be dictated by the user interface.

At step 624, input data received as input by users to invoke webservices, and output data output by invoked web services and displayedto users through one or more user interfaces are monitored. Patterns inthe input data input by users and output data displayed to users thatsuggest that an input to one web service may be obtained by invokinganother web service are identified. In this manner, aggregation of webservices may be performed as inferred from user interactions.

Consider the following example. Suppose a WSDL file describes thefollowing three web services:

-   -   (a) getISBN: which takes two strings as input and returns an        integer;    -   (b) getPrice: which takes an integer as input and returns a        floating-point number; and    -   (c) order which takes an integer as input and returns a string.        Assume that the user interface automatically generated at step        620 prompts users for inputs to each of these web services, and        that each web service can be invoked separately. If the user        causes getISBN to be invoked, and in monitoring the input data        entered through the user interface, it is determined that the        output of getISBN as displayed to the user was subsequently        entered by the user as input to getPrice and order, an inference        can be made that the output from getISBN should serve as input        data to getPrice and order. Determining whether this inference        can be employed to aggregate these web services may initially        require examining multiple occurrences of such user        interactions, to detect the pattern. Optionally, when a possible        pattern is detected, a confirmation from the user that the        inference can be validly drawn may be obtained.

In a variant embodiment of the invention, the user interface generatedat step 620 may be adapted to provide means for users to explicitlyindicate whether an input to one web service may be obtained by invokinganother web service while consuming the web services. Specific userinteractions in which users make such indications may be monitored anddetected. For example, a function representing “cut & paste” or “copy &paste” may be made available (e.g. through one or more keys, one or moreselections from a menu, etc.) to the user. Using this function, the usermay copy output data received from one web service to an input fieldwhere input data to another web service is to be entered. Use of thisfunction is monitored and its detection may provide information requiredto aggregate the associated web services.

In another variant embodiment of the invention, a user interface forcustomizing web services is generated at step 620 that permits users toexplicitly associate web services with each other by identifying whichinputs of a specific web service may be obtained by invoking another webservice (or by another invocation of the same web service). This isaccomplished through as series of customization actions as performed bythe user, in which associations between various web services are made,using menu-based selections, drag-and-drop techniques, or othertechniques known in the art. Web services may or may not be actuallyinvoked during the customization process in this embodiment of theinvention. In this embodiment, the user interface generated at step 620presents the user with a list of web services. The user may then selecta first web service. Instead of providing actual data as input for theweb service, a second web service may be selected from a menu andassociated with that input, to indicate that the output of the secondselected web service should be obtained and used as input for the firstselected web service. The web services displayed in the menu from whichthe user selects a second web service may be filtered as appropriate.For example, only web services having an output type that matches theinput type to the first web service may be displayed in the menu, forselection by the user as the second web service. At step 624,associations made by the user performing customization actions at thisstep through the user interface for customizing web services aremonitored and recorded. This facilitates the aggregation of web servicesas defined by the associations.

At step 626, a new user interface is generated by analyzing dataobtained by monitoring the user interface generated at step 620. In thisembodiment of the invention, the user interface is generated by thecomputing device, although in variant embodiments of the invention, thisstep may be performed by a device different from the computing device onwhich the user interface will be used (e.g. by a web servicesaccelerator on a remote server).

The new user interface generated at step 626 aggregates web services,such that the outputs of one or more web services when invoked (whichmay or may not themselves require input data in order to be invoked) canbe used as inputs to one or more different web services or furtherinvocations of the same web service. Accordingly, while a given userinterface may require multiple web services to be invoked, some of theseweb services can be invoked automatically without requiring the user toprovide additional input to each web service or to manually invoke eachweb service.

The new user interface is adapted to prompt a user for input data andreceive input data where required to invoke one or more web services. Itwill generally be necessary to obtain input data from the user when thedata required to invoke a web service cannot be obtained by invokingother available web services either directly or indirectly using inputdata already received. The user interface is further adapted to invokeat least one web service to obtain output data (e.g. using inputobtained from the user, using input obtained from previous invocationsof web services, using input taken from the state of the device such asthe available memory, using input taken from the device environment suchas location, using any other parameter available to the device as input,or using no input if it is not required by the web service), and toautomatically invoke another web service using that output data as inputthereto (and possibly other inputs as noted above) if appropriate, asdetermined at step 624. The latter web service need not necessarily be adifferent web service, but may alternatively be a subsequent invocationof the former web service. The user interface may then use the outputdata from the latter web service in a similar manner (e.g. as input datato automatically invoke yet another web service), and/or display theoutput data from the latter web service in a desired output format to auser.

At step 628, the new user interface generated at step 626 is stored in astorage device or memory for later retrieval (e.g. at step 614).Techniques used to track user interfaces that for re-use (e.g. a datatable to associate certain sets of one or more WSDL files with a userinterface) as known in the art may be implemented. The storage devicemay be locally coupled to the computing device, or located remote fromthe computing device, for example. User interfaces that have beengenerated and stored may themselves offer functionality that can beprovided as web services.

The user interfaces generated at steps 620 and 626 may be generatedusing any of a number of known methods. For example, each user interfacemay be generated by producing code, which can be executed immediatelyafter it is produced, or concurrently as it is produced. Alternatively,the code may be temporarily stored in a storage device or memory forsubsequent execution. The code may be produced in the form of anexecutable application, or be in the form of source code to besubsequently compiled into an executable format, for example. The codemay be in the form of data that can be used by other applications orinterfaces (e.g. web browsers) to provide the respective user interfaceto users.

Referring to FIG. 7, a schematic diagram depicting a series of examplescreens displayed to a user in an example implementation of anembodiment of the invention is provided.

In this example, screens 700 to 712 depict displays of pages from anexample user interface that permits a user to explicitly associate anumber of web services through a menu-driven user interface forcustomizing web services, as described with reference to FIG. 6 inrespect of a variant embodiment of the invention, for example. Screens714 to 720 depict displays from an example user interface in which webservices have been aggregated. It will be understood by persons skilledin the art that the information necessary to generate the example userinterface in which web services have been aggregated may be obtained byimplementations of other embodiments of the invention.

In this example, information to aggregate web services in abook-ordering interface is collected. A user is presented with a list ofweb services in screen 700. After the user selects getPrice, a new formas shown in screen 702 is displayed. Instead of filling in the inputfield for ISBN, the user brings up a menu (e.g. by right-clicking amouse) that lists other web services as shown in screen 704. A filterhas been applied so that input type of the ISBN web service is matchedto the output type of the web services listed in the menu. The userselects getISBN from the menu, which brings up a form requesting inputsto the getISBN web service as shown in screen 706. The user completesthe request as shown in screen 708. The getISBN web service is invokedand the output of this web service is shown in the form for the getPriceweb service in the appropriate field, as shown in screen 710. ThegetPrice web service is invoked, and output from this web service isreceived, as shown in screen 712. If desired, the outputs obtained fromeither the getISBN or getPrice web services may be subsequently used, toorder the book identified by an ISBN number using the available webservice [subsequent steps not shown]. The customization actionsdescribed above may then be stored in a memory or storage device.

A screen of a book-ordering interface is shown as 714. When the userselects getPrice, a form shown in screen 716 automatically incorporatingthe input fields of the getISBN web services is provided. The usercompletes the form as shown in screen 718, and submits the request. Therequest to getPrice actually makes two web service calls: one to getISBNand one to getPrice. However, the aggregation of these web services isinvisible to the user when using this interface. The result of thegetPrice call is displayed in screen 720.

Embodiments of the invention relate generally to web services, and moreparticularly to a method of aggregating web services in the generationof user interfaces for computing devices. While embodiments of theinvention may be implemented for use with wireless or mobile devices asdescribed above, by way of example, with reference to FIG. 1 throughFIG. 3, it will be understood by persons skilled in the art thatembodiments of the invention may be implemented for use with othercomputing devices, which need not be wireless. Embodiments of theinvention may be applied to both wireless and wireline consumption ofweb services.

In variant embodiments of the invention, information needed to aggregatevarious web services may be stored as meta data in a web servicedescription file. The meta data can be used to suggest which specificweb services can be aggregated, and how the web services may beaggregated. The meta data can provide hints as to various aggregationproperties, including for example: which outputs of which specific webservices need not be displayed to a user, which web services invocationsmust be made separately from others and the order in which specific webservices must be invoked to achieve aggregation, which specific webservices requires explicit user interaction, and which web services maybe invoked automatically without explicit user interaction. One or moreof these aggregation properties may alternatively be explicitly definedby a user through a user interface.

In variant embodiments of the invention, instructions for performing thesteps of a method of processing a web service description in anembodiment of the invention may be stored on computer-readable media,which may include physical or transmission-type media, for example.

The invention has been described with regard to a number of embodiments.However, it will be understood by persons skilled in the art that othervariants and modifications may be made without departing from the scopeof the invention as defined in the claims appended hereto.

1. A method of aggregating web services in generating a user interfacefor a computing device, the method comprising: generating one or moreuser interfaces through which input data is obtainable and output datais displayable; providing said one or more user interfaces, wherein inuse, at least one web service is invoked using input data obtainedthrough said one or more user interfaces, and wherein output data fromsaid at least one web service is displayed through said one or more userinterfaces; monitoring said input data obtained and said output datadisplayed during use of said one or more user interfaces to identifypatterns in said input data and said output data that suggest that aninput to a first web service is obtainable from output of a second webservice; and generating a new user interface for said computing deviceif said patterns are identified, wherein in use, the first web serviceis automatically invoked using output data from the second web servicewhen the second web service is invoked through said new user interface.2. The method of claim 1, wherein said new user interface is adapted todisplay output data from said first web service.
 3. The method of claim1, further comprising generating code for said user interface, andstoring said code in a storage device.
 4. The method of claim 3, furthercomprising transmitting said code from said storage device to saidcomputing device.
 5. The method of claim 3, further comprising executingsaid code on said computing device.
 6. The method of claim 1, whereinsaid new user interface is adapted to prompt for input data and receivesaid input data in said new user interface for invoking said second webservice.
 7. The method of claim 1, wherein said patterns are identifiedby detecting instances where said input data obtained through said oneor more user interfaces matches output data displayed through said oneor more user interfaces.
 8. The method of claim 1, wherein said patternsare identified by detecting instances in which selected data from outputdata displayed to said at least one user through said one or more userinterfaces is copied to an input field on said one or more userinterfaces, in which data in said input field is used to invoke a webservice.
 9. An apparatus programmed to perform a method of aggregatingweb services in generating a user interface for a physical computingdevice, comprising a microprocessor configured to perform actscomprising: generating one or more user interfaces through which inputdata is obtainable and output data is displayable; providing said one ormore user interfaces, wherein in use, at least one web service isinvoked using input data obtained through said one or more userinterfaces, and wherein output data from the at least one web service isdisplayed through said one or more user interfaces; monitoring saidinput data obtained and said output data displayed during use of saidone or more user interfaces to identify patterns in said input data andsaid output data that suggest that an input to a first web service isobtainable from output of a second web service; and generating a newuser interface for said computing device if said patterns areidentified, wherein in use, the first web service is automaticallyinvoked using output data from the second web service when the secondweb service is invoked through said new user interface.
 10. Theapparatus of claim 9, wherein the apparatus is a mobile device.
 11. Theapparatus of claim 9, wherein said new user interface is adapted todisplay output data from said first web service.
 12. The apparatus ofclaim 9, said acts further comprising generating code for said userinterface, and storing said code in a storage device.
 13. The apparatusof claim 12, said acts further comprising transmitting said code fromsaid storage device to said computing device.
 14. The apparatus of claim13, said acts further comprising executing said code on said computingdevice.
 15. The apparatus of claim 9, wherein said new user interface isadapted to prompt for input data and receive said input data in said newuser interface for invoking said second web service.
 16. The apparatusof claim 9, wherein said patterns are identified by detecting instanceswhere said input data obtained through said one or more user interfacesmatches output data displayed through said one or more user interfaces.17. The apparatus of claim 9, wherein said patterns are identified bydetecting instances in which selected data from output data displayed tosaid at least one user through said one or more user interfaces iscopied to an input field on said one or more user interfaces, in whichdata in said input field is used to invoke a web service.
 18. A physicalcomputer-readable medium upon which a set of software components isstored, the software components containing instructions for performingacts in a method of aggregating web services in generating a userinterface for a computing device, said acts comprising: generating oneor more user interfaces through which input data is obtainable andoutput data is displayable; providing said one or more user interfaces,wherein in use, at least one web service is invoked using input dataobtained through said one or more user interfaces, and wherein outputdata from said at least one web service is displayed through said one ormore user interfaces; monitoring said input data obtained and saidoutput data displayed during use of said one or more user interfaces toidentify patterns in said input data and said output data that suggestthat an input to a first web service is obtainable from output of asecond web service; and generating a new user interface for saidcomputing device if said patterns are identified, wherein in use, thefirst web service is automatically invoked using output data from thesecond web service when the second web service is invoked through saidnew user interface.
 19. The medium of claim 18, wherein said new userinterface is adapted to display output data from said first web service.20. The medium of claim 18, said acts further comprising generating codefor said user interface, and storing said code in a storage device. 21.The medium of claim 20, said acts further comprising transmitting saidcode from said storage device to said computing device.
 22. The mediumof claim 20, said acts further comprising executing said code on saidcomputing device.
 23. The medium of claim 18, wherein said new userinterface is adapted to prompt for input data and receive said inputdata in said new user interface for invoking said second web service.24. The medium of claim 18, wherein said patterns are identified bydetecting instances where said input data obtained through said one ormore user interfaces matches output data displayed through said one ormore user interfaces.
 25. The medium of claim 18, wherein said patternsare identified by detecting instances in which selected data from outputdata displayed to said at least one user through said one or more userinterfaces is copied to an input field on said one or more userinterfaces, in which data in said input field is used to invoke a webservice.